The present invention relates generally to the testing of logic designs, and more particularly to a method and system for automatically generating a test case for a design-under-test (DUT) from a configuration file for the DUT.
A process known as verification comprises applying test cases to a DUT and checking the results against expected results to determine whether the DUT functions correctly. Functional verification of logic designs which interface to standardized buses typically involves the use of a software tool known as a bus functional model (BFM). A BFM emulates a bus protocol to apply a test case in simulation to a DUT modeled by a hardware description language (HDL).
The BFMs allow verification engineers to write test cases as bus transactions. The bus transactions may be expressed in bus functional language (BFL) statements which are decoded and executed by the BFMs using a logic simulator. For example, a standardized BFM transaction test case for a 32 bit data slave design that uses read and write transactions with address, data, and control signal information could comprise BFL statements appearing as follows (comments indicated by “//”):    read(address=F0,be=1111,data=00000034) //4 byte read transaction from addr F0;            // byte enable (be) indicates // that bytes 0–3 are enabled;        // expected data value is 00000034;            write(address=F0,be=1000,data=12000000) // 1 byte write transaction to addr. F0;            // byte enable indicates that byte 0 // is enabled, and bytes 1–3 are not // enabled;        // 1 byte write data is 12;            read(address=F0,be=1111,data=12000034) // 4 byte read transaction from // address F0;            // byte enable indicates that bytes 0–3 // are enabled;        // expected data value is 12000034;        
In the foregoing example, read and write are two different transaction types, while address, byte enable, and data are parameters of the respective transaction types. The parameters were used to specify data to be written to an address, and to subsequently read the address to determine whether the data was correctly written.
In order to verify that a DUT completely complies with a standardized bus interface, all possible bus transactions must be performed to ensure that the DUT-to-bus interface operates under all legal bus conditions. This process, also known as regression testing, entails the enumeration of all possible and legal transaction combinations to ensure a complete and correct design.
Typically, test cases for applying all the possible and legal transactions for a DUT-to-bus interface must be specified manually, as BFL statements as shown in the above example. To code the BFL statements, a verification engineer must usually consult a bus architecture specification manual. As the complexity of logic designs increases, the number of transactions which must be applied to a design to fully test it for bus compliance becomes unmanageable by a manual procedure. The procedure becomes unduly time-consuming, and the likelihood that coding errors occur or that needed test cases are omitted increases.
In view of the foregoing, a method and system for efficiently generating test cases is called for.